Was about to create an pull request for exactly the same change. Would really like to see this merged into the master branch.

Ping, anyone?

It...doesn't really add much! :P If there were more of an implementation it would be more compelling.

Can you give an example of code that was easier to port with this?

From the python docs (https://docs.python.org/3/library/abc.html#abc.abstractmethod), the @abstractmethod decorator requires that the class’s metaclass is abc.ABCMeta or is derived from it. A common way is just to use the abc.ABC class as a base. eg (from the docs):

class C(ABC):
    @abstractmethod
    def my_abstract_method(self, arg1):

My personal use case is at https://github.com/rasjidw/sparrowrpc-python/blob/main/src/sparrowrpc/bases.py where I define a number of base classes using both the ABC class and the @abstractmethod decorator. The codebase is designed to run on both normal cpython and micropython without changes, and having the ABC class available is an essential part of that.

The is no problems with the classes and decorators being no-op classes / functions in micropython since in cpython it is really just there for developer erganomics and doesn't actually affect the runtime operation in any way.

On reflection, it is probably worth adding in the other classes and functions from the abc module as dummy entries too.

Apart from using a metaclass and slots (neither of which MicroPython supports) this is actually the same as CPython which has:

class ABC(metaclass=ABCMeta):
    """Helper class that provides a standard way to create an ABC using
    inheritance.
    """
    __slots__ = ()

So I think this is a good addition. As mentioned above, it allows doing class MyClass(abc.ABC): ....

Can you give an example of code that was easier to port with this?

Just to clarify - it is not so necessary for code that you are porting to micropython, but very useful if you want to have a single codebase that works both with cpython and micropython.

The is no problems with the classes and decorators being no-op classes / functions in micropython since in cpython it is really just there for developer erganomics and doesn't actually affect the runtime operation in any way.

Actually, this is not completely true, as the cpython ABC class has a method to register another class as a virtual subclass, which affects the result of issubclass and isinstance calls at runtime.

On reflection, it is probably worth adding in the other classes and functions from the abc module as dummy entries too.

So in fact probably better to limit this to the dummy ABC class and the dummy abstractmethod decorator.